home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19960715-19961006 / 000030_news@columbia.edu _Fri Jul 19 11:54:10 1996.msg < prev    next >
Internet Message Format  |  1996-11-03  |  2KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id LAA00582 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 19 Jul 1996 11:54:10 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id LAA00176 for kermit.misc@watsun; Fri, 19 Jul 1996 11:54:09 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Can't transfer a file from a PC to a Vax; Record too big error
  8. Date: 19 Jul 1996 15:53:47 GMT
  9. Organization: Columbia University
  10. Lines: 20
  11. Message-ID: <4sob2b$csb@apakabar.cc.columbia.edu>
  12. References: <01bb759b.82f69780$e7936bc0@loftus.idx.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <01bb759b.82f69780$e7936bc0@loftus.idx.com>,
  16. Jeannine Loftus <loftus@idx.com> wrote:
  17. : We have a client who is getting an error message attempting to Kermit a
  18. : file into the VAX
  19. : %KERMIT32-EREC_TOO_BIG, record too big for kermits internal buffersst
  20. : message.
  21. : 
  22. : I raised bytlim in the authorization record(on teh VAX) and in the
  23. : CKERMIT.SET file I raised the packet receive size from 128 to 512 bytes;
  24. : ultimately raised this to 5000 and it's still not working. I have acopy of
  25. : the error message the sender is receiving give the fiollowing:
  26. : 
  27. The problem is you are using Kermit-32, not C-Kermit, so any changes you
  28. make to C-KERMIT initialization files won't do anything.  The solution is
  29. to use C-Kermit instead of Kermit-32.  In any case, it sounds like the file
  30. that is being uploaded is not an ordinary text (otherwise you would not have
  31. records that were longer than 32,767 characters), so it should be transferred
  32. in binary mode.
  33.  
  34. - Frank